MCP 2026-07-28 readiness (waves 0-6) + #571 binding fix + two-pass security review - #550

No pg test touched MCP before this — only memoryStoreConformance,
pluginVerdictStore and skillLifecycleStore existed. Covers the registry
seed and catalog-kind backfill (0010 + 0013, including that 0013's UPDATE
actually lifts the official registry off the 'generic' column default),
the kind/auth_kind/source/registered_via CHECK sets, marketplace
provenance with ON DELETE SET NULL detaching an imported server from a
deleted catalog, the 0014 partial unique index on top-level MCP grants
(and that it leaves native grants alone), and the 0015/0016 OAuth surface
— authorize-time endpoint pinning plus token/flow cascade on server
delete. Each assertion was mutation-checked against a deliberately broken
schema.

A second suite covers what the CI gate structurally cannot: the CI
idempotency check re-applies against an EMPTY database, so it can never
catch a migration that only breaks once rows exist. It re-applies all 30
files with MCP rows in place, in its own throwaway database — re-running
0001/0003 drops and recreates the NOTIFY triggers, which must not happen
underneath a concurrently running suite.

Both suites skip when no test Postgres is reachable and scope every row
to a w04-mcp- tenant prefix. Pools are capped: the runner executes files
concurrently and ~16 other pg suites each hold a default-sized (max 10)
pool, so an uncapped extra pool here exhausts max_connections and cancels
an unrelated suite mid-run (observed on ConductorWebhookSubscriptionStore).

…capture outputSchema

Issue #547 (W1-3) — plumbing only, no canvas synthesis.

Discovery now keeps a tool's declared outputSchema: McpToolDescriptor and
McpDiscoveredTool gained an optional outputSchema, and listTools copies it
from tools/list (object-valued only; anything else is dropped). It rides
along in the existing mcp_servers.discovered_tools jsonb column, so it
survives a restart without re-discovery and needs no migration.
subAgentToolHydration rehydrates it on the way back out and seeds the
manager's cache, since mcpNativeHandler only closes over a tool name.

structuredContent is no longer discarded. A new extractStructured() reads
it and McpManager hands it to an optional McpManagerOptions.structuredSink
as { kind: 'structured_output', serverId, toolName, turnId, structured,
outputSchema? }. Error results and absent/null payloads emit nothing.

This is deliberately out-of-band rather than a widened return type.
callTool() still returns Promise<string> and NativeToolHandler is
untouched, which keeps the published plugin contract stable and keeps every
MCP result on the 'typeof result === string' path that gates Privacy Shield
masking in the orchestrator — a non-string result would bypass the shield.
The payload union is a discriminated 'kind' so #544 (MRTR) can add
'input_required' without another refactor.

renderToolResult is byte-for-byte unchanged and is now pinned by a golden
suite (text-only, mixed blocks, structuredContent-only, empty content,
array-valued structuredContent, isError, whitespace fallback, nullish). A
mutation check installs a hostile sink that rewrites and deep-mutates its
payload and returns a different object, then asserts the LLM-bound string
is unchanged; verified to fail against a deliberately in-band mutant.

Operator surface: a read-only 'returns structured output' badge in the MCP
Control Center, with en + de strings.

…ains-middleware

# Conflicts:
#	docs/CHANGELOG.md

…red-content-sidecar

# Conflicts:
#	docs/CHANGELOG.md

…le-flight refresh

Three live security/correctness defects in the MCP OAuth path.

D1 — no RFC 9207 `iss` validation. The OAuth callback trusted the `state`
parameter alone. `state` proves a response belongs to a flow we started; it does
NOT prove which authorization server issued the code, so a malicious or
compromised MCP server could steer the callback and have a code minted by one AS
redeemed at another. `iss` is now validated against the issuer bound to the flow
BEFORE the code is exchanged, so a rejected callback persists nothing — no token
row, no vault write. A mismatched `iss`, or an absent one from an AS that
advertised `authorization_response_iss_parameter_supported`, is rejected. That
advertisement is captured at authorize time in the new
`mcp_oauth_flows.iss_required` column rather than re-discovered at the callback,
for the same reason migration 0016 pinned the token endpoint: a server that can
flip the flag in between would simply opt itself out of the check.

D2 — silent 'operator' fallback (confused deputy). Both the operator router and
the runtime McpManager resolved the OAuth user key as `… ?? 'operator'`, so a
Teams or Telegram turn whose user had no mapped identity reached the customer's
MCP server holding the OPERATOR's token. Resolution now goes through the new
`services/mcpDelegation.ts` and the new `mcp_servers.delegation` column:
`per_user` yields no token when no identity resolves and the turn fails closed
through the existing `onAuthFailure` path with an explanation; `service` is the
explicit opt-in to one shared identity. The fallback literal is gone from every
call site.

D3 — refresh race. `getValidAccessToken` permitted N concurrent refreshes per
(server, user). Against an AS with rotating refresh tokens the losers get
`invalid_grant` and the last writer can persist an already-retired token,
silently disconnecting the user. Concurrent callers now share one in-flight
promise keyed by (serverId, userKey), cleared in a `finally` so a failed refresh
never poisons later attempts.

Also:
- `mcp_oauth_tokens.issuer` records which AS minted a token; a rotated issuer
  drops the stored token instead of replaying it against a different server.
- `mcp_call_log.acting_identity` records WHOSE authority each call used
  (`caller_agent` is the orchestrator slug, not the identity). Resolved via a
  new optional `McpAuthProvider.resolveIdentity`, threaded through `callTool`
  before the dispatch guard so denied calls are attributed too. An
  unattributable call is recorded as `unresolved`, never left blank.
- OAuth failure logging goes through `services/secretRedaction.ts`: tokens,
  `code`, and `code_verifier` can no longer reach a log line, including values a
  provider echoed back that we never minted. The callback's error page is
  redacted too.
- New `PUT /mcp-servers/:id/delegation` plus a delegation control in
  McpAuthSection, with `adminMcp.auth.delegation*` keys in en.json and de.json.

Tests: 40 in test/mcpOAuth.test.ts covering iss present/absent/mismatched/blank
and trailing-slash equivalence, fail-closed resolution, issuer rotation, and
redaction. The D3 test is mutation-checked — it asserts exactly ONE
token-endpoint HTTP request under 8 concurrent callers (verified to report 8 and
fail when the in-flight map is removed), not a count of mock invocations.

BEHAVIOUR CHANGE (operator-visible): a fail-closed `per_user` default for every
row would break installed deployments whose channel users reach MCP servers
today BECAUSE of the 'operator' fallback. Migration 0031 is therefore
deliberately asymmetric — every EXISTING `mcp_servers` row that already holds a
stored operator token is set to `delegation = 'service'`, preserving today's
behaviour, and only NEWLY created servers get the safe `per_user` default.
Operators must review grandfathered servers and switch the ones that should be
per-user.

…s-delegation

# Conflicts:
#	docs/CHANGELOG.md

One hung sub-agent used to pin the whole Promise.allSettled batch for the
rest of the turn: domainQueryTool awaits agent.ask() with no abort and no
timeout, and there was no per-tool deadline anywhere in the orchestrator.

dispatchTool now races an AbortSignal-backed deadline (default 120s,
OMADIA_TOOL_DISPATCH_TIMEOUT_MS, 0 disables) and returns a structured
Error: result on timeout. The abandoned dispatch is marked aborted, so a
late result is discarded before the first write into turn state (raw-result
capture, canvas sentinel, KG ingestion, privacy interning) and late
sub-agent events are dropped by an abort-guarded observer.

…rized

callTool passed no RequestOptions and silently inherited the SDK's 60s
default, so the real ceiling was undocumented and un-tunable. It now
passes an explicit { timeout, resetTimeoutOnProgress, maxTotalTimeout }
(env-tunable), where resetTimeoutOnProgress keeps long streaming calls
alive and maxTotalTimeout is the absolute ceiling.

looksTransient() also matched a bare -32001, contradicting its own
contract: the code is implementation-defined and servers legitimately use
it for Unauthorized (omadia's LoopbackMcpServer does), so a genuine auth
failure got one doomed retry before surfacing. Auth now wins; a real SDK
request timeout still retries via its "Request timed out" message.

The mutation check is captureRawToolResult: a real turn-state write the
routine runner reads back. Verified by temporarily removing the
deadlineSignal guard — the suite then fails on the capture assertion, not
on a missing error string. Also covers batch siblings resolving normally,
the 0-disables path, and a bad env value falling back to the default.

The re-apply-under-data suite originally built its private copy of the
domain in a throwaway database. That isolates correctly, but CREATE/DROP
DATABASE is a cluster-wide operation: run inside the full suite with a
test Postgres reachable, it stalled the concurrently executing
dev-platform pg suites long enough that 29 of their tests were cancelled
with "test did not finish before its parent". Reproduced deterministically
against appStore.pg.test.ts and devJobStore.pg.test.ts, and confirmed
absent from the same run with this file removed.

It now runs against a dedicated schema on one pinned connection with
`public` off the search_path. The migrations name every object
unqualified, so they build a private copy there and never touch — or take
ACCESS EXCLUSIVE on — the shared tables. Cancellations: 29 -> 0. The test
asserts the isolation itself (table count in the schema), because a
leaked search_path would turn the migrations into no-ops against the
shared tables and make every later assertion pass vacuously.

Both suites now share the file's single capped pool, closed once in a
file-level after hook.

…MCP server

W0-3 — sort the dynamic tool segments by name so the Anthropic prompt-cache
tool block is byte-stable across machines and deploys.

`buildToolsList()` stamps `cache_control: {type:'ephemeral'}` on the last tool
spec, which makes the whole tool block a single cacheable chunk. The cache keys
on a byte-exact prefix, but two of the segments feeding that block were iterated
straight out of Maps — plugin load order for the native tool registry,
`created_at` row order for domain tools — with no sort anywhere. Stable within
one process, divergent across Fly machines and across deploys: a silent,
signal-free cache miss for the tool block and everything after it.

- new `toolOrdering.ts`: `compareToolNames` (locale-pinned `localeCompare(b,'en')`
  so the result does not depend on the host's LANG/LC_COLLATE), `sortByToolName`,
  `sortBySpecName`, `normalizeDiscoveredToolOrder`
- `buildToolsList()`: native + domain segments sorted; the deliberate
  fixed-literal prefix (memory, knowledge-graph, ...) keeps its existing order
- `ToolDispatchService.listDispatchableToolSpecs()`: sorted, so the loopback
  server and the CLI bridge inherit it
- `LoopbackMcpServer` tools/list: sorted independently, because `deps.tools` is
  caller-supplied
- `resolveSubAgentTools()`: sorted (grants arrive in `created_at` order)
- `setMcpDiscoveredTools()`: normalizes by name before persisting, so a server
  that returns `tools/list` in a different order each call stops churning the
  JSONB column and any grant-epoch diff derived from it

Ordering is advertisement-only. Collision resolution is unchanged — native tools
still win a duplicate name, decided by Map insertion and never by array position
— and that is now pinned by a test whose colliding name deliberately sorts last.

W1-2 — make the loopback MCP server stateless.

`sessionIdGenerator: undefined` is the SDK's stateless mode: no session id is
issued and no session validation is performed, so the CLI bridge needs neither
the `initialize` handshake nor `Mcp-Session-Id`. The previous comment claiming
session ids "remain required by the protocol" was wrong.

SDK 1.29.0 enforces the other half of that contract — a stateless transport
throws "Stateless transport cannot be reused across requests" on its second use.
The MCP server + transport pair is therefore built per request (matching the
SDK's own stateless example) and torn down in a `finally`. Both are in-memory
handler tables with no I/O, and this server sees a handful of requests per CLI
turn. `enableJsonResponse` stays on, which also guarantees the response is fully
written before teardown.

Non-POST is now declined with 405, which the MCP spec explicitly allows for the
optional GET SSE stream. Without it the per-request transport leaks: a GET stream
never ends, so `handleRequest` never resolves and the request scope never tears
down. Under the old stateful transport a session-less GET was rejected with 400,
so nothing regresses.

Tests were written first for W1-2 and observed to fail (HTTP 400) before the
production change. The wire test is parameterized over replaying vs never
sending the session header, plus a case with no `initialize` at all. The 401
`-32001` body and the 413 oversized-POST case still hold.

Deliberately NOT implemented: the `ttlMs` tool-list cache also proposed in #545.
Its premise is false — `subAgentToolHydration` reads
`mcp_servers.discovered_tools` and never calls `listTools`, so steady state is
already ~4 wire calls per server per day — and it would re-advertise removed or
repurposed tools inside exactly the window the #454 scan-verdict gate exists to
close.

MANUAL VERIFICATION REQUIRED BEFORE MERGE: the loopback server's only consumer
is the Claude CLI bridge, spawned with `--strict-mcp-config --mcp-config <path>
--allowedTools mcp__omadia__*`. If the installed CLI refuses to proceed when the
server issues no `mcp-session-id`, the bridge yields a server with ZERO tools and
the turn silently degrades to a toolless answer rather than erroring — no
automated test catches that. A pass against the real `claude` CLI with the
stubbed `createLoopbackServer` bypassed is needed. Not performed here: spawning a
nested `claude` session is blocked in this environment. Installed CLI version on
this machine is 2.1.220.

Nothing in the repo proved the client could complete an initialize →
tools/list → tools/call sequence: mcpCallAudit dials a refused port,
mcpRescan stubs listTools, and the cliBridge tests stub the server. These
drive a live in-process LoopbackMcpServer, sometimes through a recording
proxy that injects one transport-level failure, so retry and pool
behaviour are observed rather than inferred:

- listTools + callTool succeed over the wire; a second call reuses the pool
- a successful call is audited as ok (previously uncovered)
- a genuine Unauthorized surfaces immediately: exactly one POST, exactly
  one pool invalidation (fails if -32001 is classified transient again)
- the shipped once-retry still fires exactly once for -32000 and then
  succeeds, dropping the pooled connection once
- a stale token invalidates the pool and the next call reconnects

…dline-and-mcp-client-tests

…-28)

MCP 2026-07-28 reclassifies the legacy HTTP+SSE transport as Deprecated with a
minimum 12-month removal window. Discourage 'sse' for NEW registrations while
keeping every existing SSE server fully working — no protocol work,
SSEClientTransport stays wired and the DB CHECK is untouched.

- DEPRECATED_MCP_TRANSPORTS + isDeprecatedMcpTransport in mcpClient.ts as the
  single source of truth, re-exported from @omadia/orchestrator.
- mcpNode() gains an additive transportDeprecated flag derived from it (no
  migration); exported for unit tests.
- Marketplace import path (the second way an sse row can be minted): prefer an
  http remote when a catalog entry offers both, still allow an sse-only entry
  but flag it via McpCatalogEntry.transportDeprecated.
- web-ui McpServerNode gains optional transportDeprecated; McpTransport keeps
  'sse' (published plugin contract stays as-is).

Refs #541

…ggle

Issue #541 acceptance 4 + 6. http (Streamable HTTP) stays the default and the
only remote option shown; 'sse' appears in the picker only after ticking 'Show
deprecated transports', labelled '(deprecated)'. Existing sse rows get a
Deprecated badge in the transport column with a hint pointing at Streamable
HTTP as the migration target.

Nothing is hard-blocked: the MCP removal window is at least 12 months, so an
operator can still deliberately register a legacy SSE server.

i18n: adminMcp.servers.{transportDeprecated,transportDeprecatedHint,
showDeprecatedTransports,deprecatedOption} in both en.json and de.json.

Refs #541

…gression

- mcpRegistryClient: prefers http when a catalog entry offers both remotes,
  still imports an sse-only entry (flagged), and the preference cannot bypass
  the untrusted-remote guard; the pre-existing sse fixture now also asserts
  transportDeprecated.
- mcpNode: transportDeprecated true for sse, false for http/stdio.
- Regression: an sse config still yields a real SSEClientTransport (and http a
  StreamableHTTPClientTransport) — the unit discourages, it does not remove.

Refs #541

Issue #541 acceptance 8 + 9. First test file for the MCP Control Center page:
the picker offers only http/stdio by default, exposes 'sse (deprecated)' after
ticking 'Show deprecated transports' and lets it be selected (never
hard-blocked), resets to http when the toggle goes off, badges existing sse rows
and falls back to the local list when an older middleware omits the flag.

Refs #541

…n' into feat/mcp-2026-07-28-wave0-wave1

# Conflicts:
#	docs/CHANGELOG.md

…t' into feat/mcp-2026-07-28-wave0-wave1

# Conflicts:
#	docs/CHANGELOG.md

…-sidecar' into feat/mcp-2026-07-28-wave0-wave1

# Conflicts:
#	docs/CHANGELOG.md
#	middleware/packages/harness-orchestrator/src/mcp/mcpClient.ts

…er-and-stateless-loopback' into feat/mcp-2026-07-28-wave0-wave1

…cp-client-tests' into feat/mcp-2026-07-28-wave0-wave1

Lift the shape devJobOrchestratorTool.ts hand-rolled (start returns a
handle at once, work runs detached, a card streams into the turn) into a
reusable seam so any tool can be marked longRunning.

- taskTypes.ts: TaskDescriptor + TaskStore/TaskReadStore, with a status
  vocabulary (working | input_required | completed | failed) chosen to
  project mechanically onto MCP Tasks later.
- inMemoryTaskStore.ts: reference implementor of the claim/lease and
  terminal-transition semantics.
- longRunningTool.ts: defineLongRunningTool() -> the non-blocking
  <tool>_start / _status / _list triple + pending card buffer.
- taskReaper.ts: orphan sweep (abandoned live tasks, accumulated
  terminal tasks).
- subAgentTaskTool.ts: deferred sub-agent dispatch as second consumer.

No MCP Tasks protocol handlers: internal LocalSubAgent dispatches never
cross an MCP boundary, and SEP-2663's tasks/update is unshipped.

Client ID Metadata Documents (issue #546) become the third link of an explicit
acquisition chain: stored -> cimd -> dcr (deprecated, warns) -> manual.

Corrects the issue's premise: the OAuth 2.1 + PKCE stack already shipped in
epic #459 W9, so this is a delta on it. CIMD replaces Dynamic Client
Registration at MCP-native brokers only -- Entra ID and Okta do not support it
and keep using the existing manual path, which has no sunset. DCR is kept
working and merely warns.

- migration 0032: 'cimd' in the registered_via CHECK set + client_metadata_url
- GET /.well-known/omadia-mcp-client, allowlisted via the shared constant
- 501 (not 500) when FLOW_PUBLIC_BASE_URL is unset -- CIMD needs INBOUND https
  reachability, so a firewalled install degrades to manual instead of breaking
- SSRF guard reuses assertPublicHttpsUrl on the metadata probe
- describeAuth gains acquisitionMode / cimdSupported / cimdBlockedReason

Additive adapter (new file only): projects DevJobStore onto the generic
TaskStore seam - ten-value DevJobStatus down to the four-value
MCP-Tasks-shaped vocabulary, dev_job_events onto the seam's event tail,
claimNextQueued onto claimNextPending, and finalizeDevJob onto finish so
the brand-gated terminal choke point is preserved.

Zero edits to devJobStore.ts / devJobOrchestratorTool.ts and no
migration: dev_job_start still returns {"status":"job_started",...} so
the web-ui card parser and existing tests are untouched. Keeping this in
its own file also keeps the in-flight dev-platform plugin extraction
(PR #536/#538) to a file move rather than a conflict.

Documents the one intentional divergence: the seam's finish() is
lease-fenced, dev_job's finishTerminal deliberately is not (cancel routes
and the reaper finalize jobs they never claimed), so the adapter accepts
a matching lease OR no lease, and rejects a mismatched one.

Extend the lenient CallToolResult schema with resultType + inputRequests,
both readable off the shipped SDK 1.29.0. An input_required result parks
the call in a new PendingMcpInput store keyed on the
{userId, sessionId, correlationId} triple and returns a stable sentinel
to the model instead of a result: no retry attempt consumed, no failure
audit row. The MCP call audit gains a three-valued outcome so a parked
call is neither reported as a failure nor as a delivered result.

Rides W1-3's McpSidecarKind union, which was shaped for exactly this
second member.

…guard, migration 0032

- strategy chain: stored beats cimd beats dcr beats manual, each asserted via an
  OBSERVABLE consequence (which client_id reaches the provider, what was
  persisted) rather than a mock call count
- CIMD skipped when the AS does not advertise support, when no metadata URL is
  configured, and when the document is not inbound-reachable
- metadata endpoint shape, 501 without FLOW_PUBLIC_BASE_URL, and a direct
  assertion that served redirect_uris === McpOAuthService.redirectUri
- SSRF rejection of loopback / RFC1918 / link-local / non-https metadata URLs,
  including that no request leaves before the guard runs
- publicPaths asserted against the shared CIMD_METADATA_PATH constant
- migration 0032 pg test isolated in a dedicated tenant SCHEMA (never a scratch
  database: CREATE/DROP DATABASE is cluster-wide and cancels concurrent suites)

…cy invariants

31 tests across the reference store and the registration helper. Each
invariant was verified by deliberately breaking it, rebuilding, and
confirming a real assertion failure:

- M1 lease fence removed          -> claim+lease suite fails
- M2 reaper keyed on heartbeat only -> never-claimed-orphan test fails
- M3 task input copied onto a card  -> privacy invariant test fails
- M4 takePendingCards stops draining -> card test fails
- M5 terminal immutability guard removed -> zombie-worker test fails

M5 initially SURVIVED: finish() cleared the lease, so the lease check
alone carried terminal immutability and the guard was unreachable. Fixed
properly rather than by weakening the claim - reapOrphans now PRESERVES
claimedBy, which is the correct semantics (the reaper is not the owner,
and a zombie worker waking up after being reaped legitimately still holds
a matching lease). The guard is now the only thing rejecting it, and the
new zombie-worker test fails without it.

… statement

A pool-level 'SET search_path' binds only the one pooled client that served it,
so the next query lands on a different client and silently resolves against
public. Two assertions failed on the first real run because of it. The
search_path is now a connection option on a dedicated pool, with a separate
admin pool for CREATE/DROP SCHEMA.

Every per-request control here is charged once per HTTP request:
`requireApiKey`'s rate limiter takes ONE token, and `tools/list` never
touches the concurrency counter. A JSON-RPC batch is one HTTP request
carrying many messages, so a single sub-8-MB array of tens of thousands of
`tools/list` calls costs the caller one token and costs the server that
many `bindings.get` round-trips to Postgres. The write limiter still
covered writes; reads and listing were free.

Reachable, not theoretical: the SDK's transport delegates to
`WebStandardStreamableHTTPServerTransport`, which maps over `rawMessage`
whenever `Array.isArray`.

Refused outright rather than rate-limited per message. It is the smaller
fix and the spec-correct one — MCP removed JSON-RPC batching in the
2025-06-18 revision and this endpoint implements 2026-07-28 — where
per-message limiting would mean reaching back into a limiter that lives one
middleware upstream, for a shape the protocol no longer defines.

Placed before `requireApiKey` so an unauthenticated batch also costs
nothing. Three cases: a batch is refused as -32600, a 5000-message batch
sitting deliberately UNDER the byte cap is refused on shape rather than
size, and — as the guard rail — an ordinary single request still passes.
Mutation-checked: removing the guard fails both refusals and leaves the
guard rail green.

…handler errors

Two defects on the public endpoint, both in the same call path.

TIMEOUT RELEASES A SLOT WITHOUT STOPPING THE WORK. `withTimeout` is a
`Promise.race`, and losing a race does not cancel the loser — nothing in
ToolDispatchService accepts an AbortSignal. The slot was released in a
`finally` on the RACE, so every timeout reopened a slot while the
Odoo/M365/MCP/sub-agent call behind it stayed alive. A caller hammering a
tool that hangs on an upstream connection accumulated unbounded sockets,
promises and external work while the endpoint still advertised a ceiling of
`maxConcurrentCalls`. The release now rides on the WORK, so the ceiling
counts what is actually running. Cancellation would mean threading an
AbortSignal through every handler and belongs on its own.

HANDLER ERRORS REACHED THE CALLER VERBATIM. `handleHttp`'s catch answers a
bare 'Internal server error' and is unreachable for anything a request
handler throws: the SDK converts a handler rejection into a JSON-RPC error
built from `error.message` (`shared/protocol.js`) and then RESOLVES, so
`handleRequest` never rejects. A failing `bindings.get` therefore handed an
external, merely API-key-authenticated caller a Postgres diagnostic — the
relation name, the database host, a driver string. Both handlers now route
through `sanitized()`, which passes deliberate `McpError`s through
untouched and turns anything else into a generic error, logging the real
one server-side.

Tests: the slot is still held after a timeout and returns once the
abandoned work settles; a store failure leaks neither the relation name nor
the internal hostname, on `tools/call` and `tools/list`. The harness gains
a `bindingStore` override, since a FAILING store is not expressible through
`bindingRows`. Both mutation-checked.

…anonicalise the issuer

SIZE CAPS RAN AFTER FULL BUFFERING. `await res.text()` followed by a length
check is not a cap: by the time the check runs the whole body is resident.
A discovered authorization server can stream hundreds of megabytes inside
the request timeout and the process allocates all of it before deciding it
was too large. `mcpOAuthClient`'s token and registration responses had no
cap at all — and those are the two endpoints whose URLs come from an
untrusted document.

`readTextCapped` meters the stream and cancels the reader the moment the
cap is passed, so the socket is torn down rather than drained. It also
honours a declared oversized `content-length` as a fast path. Applied to
metadata discovery (256 KB), the CIMD probe (64 KB), and both OAuth client
POSTs (256 KB). A `Response` with no body stream — a hand-built one in a
test fake — falls back to the previous buffered read plus the same cap, so
no fixture changes and no real network path takes that branch.

CANONICAL ISSUER. `AuthServerMetadata.issuer` now carries the issuer we
FETCHED rather than the string the document echoed back. The RFC 8414 §3.3
guard has already proven the two are the same identifier, so the only
remaining difference is trailing slashes — and that spelling is what keys
`loadClient()` and the stored token rows, where a document answering
`https://as.example/` could miss a client stored under `https://as.example`.
Taking the canonical form also retires the question of how many trailing
slashes `sameIssuer` should tolerate for everything downstream.

…sertion

The public endpoint requires that masking actually RAN for the current
dispatch — a positive signal, because 'did not fail' cannot distinguish
success from never-ran. An idempotency replay cannot satisfy that by
observation: no handler runs, and the gate is built per request, so
`masked()` is false however well the cached body was masked when it was
produced.

So a retried write — the exact case idempotency exists for — was answered
with 'privacy masking did not run'. That is the worst available reply: the
write DID commit, the endpoint suppressed the duplicate correctly, and the
caller is told something that reads like a failure and learns nothing about
whether the mutation happened.

`ToolDispatchResult.replayed` now marks a cache hit and the assertion
exempts it. Narrow and safe: the body crossed this same boundary on the way
in, and since idempotency is namespaced by principal (previous commit) a
replay can only ever be returned to the principal that produced it. Digest
RESOLUTION does not carry over — those bindings belong to the earlier turn.

The test for this was vacuous on the first attempt and the mutation check
caught it: `realDispatcher` wired no `ToolIdempotencyStore`, so
`dispatchIdempotent` skipped the cache and the case was two ordinary
dispatches that both masked fine — green with the exemption removed. The
harness now takes `idempotency: true`, and the test counts REAL handler
executions as its oracle, so 'no replay happened' fails loudly instead of
passing quietly.

The 8 MB gate measured `JSON.stringify(req.body)`. JSON is mostly
insignificant whitespace, so that is not the size of anything that was
received: a chunked body carrying megabytes of spaces around `{}` declares
no `Content-Length`, re-serializes to two bytes, and passed both the
declared-size and re-serialized checks — while costing the full transfer to
read and parse.

The one place the real figure exists is `express.json`'s `verify` hook,
which sees the raw buffer before parsing. `http/rawBodySize.ts` records it
on the request and the gate now prefers it, keeping the re-serialized check
as the fallback for requests that never met a `verify`-wired parser (a
raw-body route, a hand-built test request) — a weaker check where the real
figure is unknown beats none.

NOT fixed here, and worth stating plainly: the global parser still reads and
allocates up to its own 10 MB limit before ANY route runs, authentication
included. Lowering that ceiling affects every route in the application and
is a separate decision, not something to slip into an MCP commit.

Also restores two mutation-harness entries that my earlier edit to the
masking assertion silently invalidated — the harness reported them
'SKIPPED (mutation no longer applies)' and the run fell from 39/39 to 37/39.
A mutation that stops matching is lost coverage that still looks like a pass,
so both are re-pointed at the new source, and the replay exemption added in
the previous commit gets its own entry.

…audited

`mcp_call_log.error` carries a remote MCP server's own protocol/transport
message. The orchestrator bounds it to 300 characters and the comment there
notes external error strings can carry upstream data — but truncation is not
redaction. A server that echoes `refresh_token=…`, an
`Authorization: Bearer …`, or a secret-shaped JSON field puts that
credential into an append-only table, and the operator audit API returns the
stored string verbatim.

Redacted in the `onToolCall` sink rather than at the write in
`mcpClient`: `secretRedaction` lives in this package and the sink is the
injected seam, so the alternative was a second copy of the patterns inside
`@omadia/orchestrator` — and two copies of a redaction rule is one that
drifts loose.

LIMIT, stated rather than papered over: this removes CREDENTIALS, not PII.
An upstream error quoting a customer name or address still lands in the
table. Masking that means running the privacy pipeline inside the audit
writer, which is a design decision, not a patch.

Coverage note: `redactSecrets` itself is covered by `mcpOAuth.test.ts`;
this commit is two lines of wiring in the boot path, which has no unit seam
short of booting the app.

`NewTaskInput.createdBy` was documented as 'who asked for it — for scoping
reads' and `TaskListFilter.createdBy` existed to filter on it. Neither was
ever passed. `_start` created tasks with no owner, `_list` filtered on
`kind` alone, and `_status` accepted any task id. Two callers of the same
deferred tool could therefore enumerate each other's tasks — terminal ones
included, which carry `result` and `error` — and then poll each id for its
full event and result stream.

An injection point declared but never threaded through to its consumer,
which is the same shape as a long line of prior defects in this codebase.

`TaskDescriptor` now exposes `createdBy` so a READ can check it: `_status`
takes an id and nothing else, and the alternatives were to trust the id or to
re-list and hope the task fell inside the page limit. `_status` answers the
identical 'not found' string for 'no such task' and 'not yours', because
distinguishing them makes the handler an existence oracle over other callers'
task ids.

Owner comes from `currentDispatchCaller().principal` (the API-key id on the
public MCP path) or `turnContext.mcpUserKey` (chat and channel turns). Both
are server-attested, so neither can be spoofed. When neither resolves the
owner is the literal `'unidentified'` rather than `undefined` — an absent
value would DROP the optional filter and list everything, reintroducing the
leak on the one path that has no identity. Grouping unidentified callers is
the honest floor, not a guarantee. `createdBy: null` stays unscoped, which
is what dev_job wants: operator-initiated work behind an authenticated admin
surface.

Reachable only with `LONG_RUNNING_SUBAGENT_TOOLS` set; it defaults to empty.

Both halves mutation-checked separately, since they are enforced by different
mechanisms — `ownsTask` for the poll, the `createdBy` filter for the list —
and a single mutation only exercises one. GOTCHA worth recording: these tests
import from `@omadia/orchestrator`, i.e. the BUILT package, so a mutation in
`src/` proves nothing until the package is rebuilt. The first attempt at both
checks passed for exactly that reason.

…lementor names

CARD LEAK. Every `_start` pushed a card onto `pendingCards`, and
`takePendingCards()` — the only drain — has no production consumer on the
deferred sub-agent path: `subAgentToolHydration` keeps
`handle.registrations` and discards the handle. So the array grew for the
life of the process, one entry per call. The task reaper cannot help; it
clears task rows, not this closure's array. Capped at 100, dropping the
OLDEST, since surfacing these cards is unshipped work and the newest is what
a consumer would want if one ever attaches.

DECOUPLING RATCHET. The previous commit's explanatory comments named the
seam's first implementor three times inside `@omadia/orchestrator`, plus
once more in core, taking the epic #470 ratchet from 3448 to 3452 and
failing CI. Both halves of that are wrong, not just the count: this PR
already contains a commit titled 'describe the task seam by contract, not by
its first implementor', and my comments walked that back. Reworded to
describe the CONTRACT — 'an implementor that scopes no reads', 'implementors
that ship their own card consumer' — which is both what the ratchet wants
and what the seam's own design decision says. Held at 3448, no baseline
raise.

Worth recording: the ratchet counts TEXTUAL references, comments included.
A comment that names the thing being extracted moves the number the same as
an import does.

…y failure

Three defects from the second cross-vendor pass. The first is a hole I
introduced with the replay exemption.

REPLAY COULD SMUGGLE AN UNMASKED BODY PAST THE ASSERTION. The idempotency
store retained a dispatch result BEFORE the endpoint asserted that masking
had run, so the ordering was: unmasked body cached → first request correctly
refused → retry replays that cached RAW body, flagged `replayed` and
therefore exempt from the very assertion that had just rejected it. My
comment claiming the cached body 'crossed this same boundary on the way in'
was simply false. Reachable through a dispatcher that omits `withPrivacy`
(which the interface permits) or any future masking regression — precisely
what a fail-closed control exists to contain.

Fixed by asking the question at the right time: `ToolDispatchOptions.validateResult`
runs the caller's admissibility check INSIDE the store's `exec`, so a
refused body throws before retention and the store keeps no rejected
outcome. That also covers the concurrent duplicate, which collapses onto the
same execution and would have been handed the poisoned body before any
after-the-fact invalidation could run. The post-dispatch check stays as
defence in depth for the replay path and for dispatchers that ignore the
option.

DECLARED-OVERSIZE RESPONSES WERE NOT CANCELLED. `readTextCapped` returned
`null` on an oversized `Content-Length` without cancelling the body, and
the caller then cleared its abort timer — so a server answering
`Content-Length: 100000000` and trickling forever pinned a socket per probe.
Cancel first, then return.

FAILURES WENT UNAUDITED. The catch treated 'is an McpError' as 'already
audited'. Wrong in both directions: the TIMEOUT is an McpError minted inside
`withTimeout`, which records nothing — so a write that may have committed
upstream produced no row at all — and the masking refusal, now thrown from
inside `dispatch`, no longer passed the record that used to sit beside the
check. Replaced with an explicit written-once flag, so every failure lands
exactly one row and no path lands two.

Tests: an unmasked result refused on the first call must also be refused on
retry rather than served from cache; a timed-out call produces an audit row;
a masking refusal produces exactly one. All three mutation-checked —
restoring the `McpError` assumption fails the timeout case.

…udit sinks

Two halves of the same gap, from the second cross-vendor pass.

ONE SINK HAD NO REDACTION. `mcp_call_log` is written from two places — the
runtime observer and the Agent Builder sandbox observer — and only the
runtime one redacted. A sandbox test-call persisted the credential verbatim
into the same table. Both now go through `redactAuditError`, a shared
structural helper rather than a copy-pasted expression at each call site,
because a copy-pasted transform is precisely how one sink ended up redacting
and the other not.

THE PATTERNS ONLY KNEW OAUTH. This redactor was written for OAuth error
bodies, then picked up a caller that stores error text from ARBITRARY
upstream MCP servers. Those are not OAuth providers and do not use RFC 6749
spelling, so `X-API-Key: sk_live_…`, `Authorization: Basic …`,
`accessToken`, `clientSecret`, `api_key` and `password` all matched
nothing and were persisted in full. Added camelCase and generic credential
field names, a header-value rule for `X-API-Key`-style headers, and `Basic`
alongside `Bearer`. Header and scheme NAMES are kept — knowing which
credential was rejected is why the line is worth storing.

Five cases, including a guard rail that ordinary error text passes through
untouched: an over-broad redactor destroys the diagnostic value of every log
line, which is its own failure mode.

Unchanged limit: this removes CREDENTIALS, not PII.

…es both issuer spellings

Two low-severity findings from the second cross-vendor pass, both the same
mistake in different places: a check that answers 'is there a row' where the
caller needs 'would a real request resolve this'.

EXISTENCE CHECKS COUNTED DEAD STATES AS LIVE. `knownAgentIds` included
agents with `status: 'disabled'`, but dispatch resolves against the ACTIVE
registry. `knownKeyIds` included revoked keys, but authentication skips a
revoked record. So an operator could bind a revoked key to a disabled agent,
get a 201 with no warnings, and see a green row — the exact
dead-but-configured-looking state #571 added these checks to prevent, one
layer along. Both sets now filter to what would actually resolve.

CLIENT ROWS ARE KEYED BY ISSUER STRING, COMPARED BY `sameIssuer`. Two rules
over one value: the comparison treats `https://as.example` and
`https://as.example/` as the same identifier, the storage lookup does not.
A client stored under one spelling is invisible to a lookup using the other,
so rotation detection says 'same issuer' while `loadClient` says 'no
client' and the install is pushed into another acquisition flow, or simply
cannot refresh. `loadClient` now tries both spellings, exact first.

Deliberately NOT normalising the key outright: that would orphan every row
already written with a trailing slash. Trying both is backward compatible,
and an install that never hit this keeps its single lookup.

…he new guards

42 caught, 0 skipped.

Two of my own commits silently invalidated harness entries by editing the
source they match on — extracting `assertMaskingCrossed` changed the
assertion's indentation, and adding the wire-byte cap rewrote the body-cap
condition. Both showed as 'SKIPPED (mutation no longer applies)', which is
lost coverage on the endpoint's most important controls while still reading
like a normal line in the output.

Also adds entries for three guards that had none, all added by this run of
fixes: the wire-byte measurement specifically (distinct from the byte cap
generally, so dropping it fails the re-serializes-small case), the JSON-RPC
batch refusal, and the idempotency-replay exemption.

Worth knowing about this harness: it matches EXACT source strings, so any
refactor of a guarded line silently drops its mutation. It is run by hand —
not wired into CI — so nothing else notices. The wrapper I was driving it
with also ended on `echo`, which meant a non-zero harness exit was reported
as success; that is fixed on my side but the harness's own
`[ "$fail" -eq 0 ]` was always honest.